Method and system for defining and controlling algorithmic elements in a graphics display system

ABSTRACT

An API is provided that enables programmability of a 3D chip, wherein programming or algorithmic elements written by the developer can be downloaded to the chip, thereby programming the chip to perform those algorithms. A developer writes a routine that is downloadable to a 3D graphics chip. There are also a set of algorithmic elements that are provided in connection with the API that have already been programmed for the developer, that are downloadable to the programmable chip for improved performance. Thus, a developer may download preexisting API objects to a 3D graphics chip. A developer adheres to a specific format for packing up an algorithmic element, or set of instructions, for implementation by a 3D graphics chip. The developer packs the instruction set into an array of numbers, by referring to a list of ‘tokens’ understood by the 3D graphics chip. This array of numbers in turn is mapped correctly to the 3D graphics chip for implementation of the algorithmic element by the 3D graphics chip.

CROSS REFERENCE OF RELATED APPLICATIONS

This application is a continuation of U.S. patent application Ser. No.09/796,577, filed Mar. 1, 2001 now U.S. Pat. No. 7,159,041, which claimsthe benefit of U.S. Provisional Application Ser. No. 60/187,535, whichwas filed on Mar. 7, 2000, herein incorporated by reference.

FIELD OF THE INVENTION

The present invention provides a new and improved software interface asa layer between application developers and the graphics pipeline thatrenders and processes the graphics data.

BACKGROUND OF THE INVENTION

For the vast majority of applications, application programmers rely onor utilize some form of software interface to interact with a computerand its associated devices. For graphics applications, developers orprogrammers typically utilize a graphics software interface, such as a3D graphics application programming interface (API), to facilitate theinteraction with constituent parts of a graphics system. Programmerstypically rely on software interfaces to peripherals and devices so thatthey can focus on the specifics of their application rather than on thespecifics of controlling a particular device and so that their effortsare not duplicated from application to application. However, even aftergenerations of software interfaces, there are certain aspects of today'ssoftware interfaces that do not provide the level of performance desiredand thus can be improved.

There are several reasons why previous generation graphics softwareinterfaces do not meet the needs of today's graphics applications andsystems. One type of resource contention issue that sometimes occurs isdue to the demands of multiple devices and applications requiringgraphics system resources simultaneously. For example, if multipleapplications running simultaneously are maintaining connections tomultiple surfaces from various objects of the graphics system, sometimesthese connections to surfaces can become severed or disconnected. Whenmultiple applications have connections between surfaces and objects,more system resources, such as memory space, are utilized resulting inan increased likelihood of a disconnection. For instance, while a usermay generally toggle back and forth between executing applications, ifthe connection to surface memory for any one application is severed, auser may have to restart the application or begin certain portions ofthe application again in order to recreate a proper connection. Today's3D graphics APIs check for severing of connections in a redundantfashion, wasting computing resources, and consequently there is a needfor an improved technique for checking for the persistence ofconnections between object space and surface space.

Another reason why previous generation graphics software interfaces areinadequate is that versioning itself can create problems when eachversion is not rewritten from scratch, as is often the case. As anysoftware developer has encountered, the subsequent versioning of asoftware product to meet the ad hoc needs of an evolving operatingenvironment produces a scenario where once separate or merely relatedmodules may be more efficiently placed together, rewritten or merged. Asoftware interface between graphics application developers and rapidlyevolving hardware is no less a product. For example, graphics APIs haveundergone multiple evolutions to arrive at the current state of the artof graphical software interfacing. In some cases, this in turn hascaused current versions of the API code to become unwieldy todevelopers. For example, the 3D graphics world has grown exponentiallyin the last decade, while the procedures for 2D applications havelargely stayed the same. Initially, there was only an API that helpeddevelopers render 2D images, and while at its inception, the API was arevolutionary innovation freeing developers to create games and other 2Dgraphics applications, the algorithms for the creation, processing andrendering of pixels and polygons in 2D space have been largely static inrecent years. On the other hand, the algorithms for the creation,processing and rendering of 3D objects on a 2D display space have grownconsiderably. While the creation, processing and rendering of 3D objectsby a 3D API utilizes algorithms and function calls of the 2D API, asingle set of APIs does not exist for the purpose of creating both 2Dand 3D objects. There are thus typically multiple choices for adeveloper to make, when creating, processing or rendering an object,because there are multiple roads to the same result depending upon whichAPI function calls are utilized to achieve the result.

For yet another example, there are three ways for a developer to performa texture download depending upon the hardware involved, wherein data istransferred from the system memory surface to the display memorysurface. It would be desirable to provide a single fast texturedownload. There are thus situations where the number of mappings from anapplication to various API objects is diverse, whereby multiple commandsperform the same or similar actions. In essence, there is an overlappingof functionality among API objects that is not exploited. It would thusbe desirable to centralize this diversity and provide a unified singularcommand structure, thereby reducing the number of diverse, andpotentially redundant, mappings to API objects.

In addition, there are a number of instances in which existing 3Dgraphics APIs inconvenience the developer by requiring the developer towrite substantially more complex code than is necessary in view oftoday's computing environments. For example, currently it requires atleast five programming steps to effect a resolution change,inconveniencing the developer each time a resolution change is desired.While coding five steps is still better than interfacing directly withgraphics system components, it would still be desirable to provide asingle command to effect a resolution change. Thus, there are a varietyof instances in which it would be desirable to unify existing APIcommand structures into concrete, atomic algorithmic elements that easethe task of development.

Since graphics peripherals and other specialized graphics hardware andintegrated circuits (ICs) are generally designed for specific tasks,they are much better than the host processor at performing certain typesof functions. For example, a video card may have special purposehardware that can copy or process pixels much faster than the CPU. Ahigh level interface using a multi-purpose processor may not takeadvantage of the specialized functionality and may also includeadditional lines of code that in the long run can consume valuablecomputer resources, especially when repeated over and over as can be thecase with graphics applications. Thus, one of the problems with current3D graphics architectures is an over-reliance on general host computingresources. This over-reliance on general processing has led to majoradvances in specialized graphics chips designed primarily for thepurpose of improving the performance of graphics applications.

Other failings in today's graphical software interfaces are due toadvances in hardware technology that have enabled the ability to movefunctionality previously implemented in software into specializedhardware. An example of this is the way in which graphics rendering andprocessing functionality has been merged or pushed into specializedgraphics hardware that can operate, on average, at orders of magnitudefaster than previous generations. In the last two years, graphicshardware has been matching or beating the expectations of Moore's law,creating a whole new universe of high performance devices and 3Dgraphics chips that can perform specialized tasks at previously unheardof rates and efficiency. This in turn has left pre-existing softwareinterfaces lagging behind the functionality of the hardware devices andthe graphics community, and in certain cases, the software interfacesare currently limiting this increased hardware functionality. This canbe the case, for example, when the execution of the commands of thesoftware interface becomes the rate determining step of a graphicsoperation that could otherwise be performed more efficiently withhardware. Thus, in addition to the problems identified above, it wouldbe desirable to address with software solutions the increasedfunctionality of today's graphics hardware at various points betweendevelopers, the 3D graphics API and the new hardware.

For example, in the past, when a developer switched graphics data fromone memory location to another, the developer had to deal with switchingthe data i.e., by destroying and recreating the data. In this regard,there are two types of ‘containers’ that today's graphics APIs presentto a developer for use: one for pixels and one for polygons.Essentially, by passing arguments to the graphics API (placing data intothe containers), the developers can manipulate and render various chunksof data. Once these containers are filled with data, there are variousplaces, such as system memory or on a 3D card or chip, where this datamay be stored for further manipulation. The filling and placement of thecontainers is achieved via various components or function calls of thegraphics API. The decision as to where to place this data is generally aperformance issue. Data for which fast access is not necessary can bestored in system memory, whereas data for which speed of access is moreimportant may be stored on a graphics chip designed for ultra fastaccess.

As mentioned, it is sometimes desirable for a developer to switch dataor chunks of data from one memory location to another memory location atdifferent stages of processing. In the past, when a developer desired toswitch data from one memory location to another, the developer had todeal with switching the data i.e., destroying the data in the oldlocation and recreating the data in the new location. Previously, thismay not have caused a performance decrease because, relative to today,the bandwidth for high performance processing on a graphics board orchip was low. This may have actually given the developer moreflexibility to place data in an environment in which it would beprocessed most efficiently. With limited options, this task was notoverly burdensome even though the developer had to custom code theswitching of data for each application.

Given the complexity and high performance rewards of using today'shardware, which may have their own memory on board or on chip, it wouldbe advantageous to be able to automatically transition data objectsbetween memory types to enable the seamless switching of data. It wouldin theory be desirable to keep all data on the faster hardware chipmemory to process data. However, in reality, there is little room forsuch on chip graphics data, sometimes as few as a hundred (high speed)registers. Thus, typically a cache managing algorithm optimizes thetradeoff between host system memory and video memory on the 3D card orchip so as to keep a maximum amount of data for processing in graphicshardware memory without causing overflow. Previously, a developer wouldhave to write such a cache managing algorithm for every application andthe cache managing algorithm would have to be individually tailored tothe programming task at hand. Thus, it would be desirable to enable thesoftware interface to hide the optimal cache managing algorithm from thedeveloper so that the developer need not be concerned with the optimaltradeoff of system resources, and so that efficient switching of datacan take place behind the scenes, thereby simplifying the developer'stask.

Another area in which such a software solution is desirable in view oftoday's graphics devices lies in the transmission of graphics data tospecialized graphics ICs and other specialized devices. For example, asmentioned, there are two types of data containers, pixel and polygon,that a developer may fill with data objects for further operation andprocessing. These containers correspond to data structures or formatsthat graphics modules, ICs and devices have come to expect for theprocessing and storage of graphics data, such as pixels and polygons.Currently, when a developer goes about specifying multiple data objectsto fill multiple containers, these data objects are fed to a 3D chip oneby one, or in a serial fashion. Thus, currently, developers are not ableto feed graphics data objects in parallel to a 3D chip for processingand yet today's 3D graphics chips have evolved to function upon and/orstore multiple data objects simultaneously.

Another area in the graphics world that has rapidly evolved is in thearea of procedural shading. Vertex and pixel shaders, which may beimplemented with software or hardware or with a combination of both,have specialized functionality that enables the processing of pixels orvertices, so as to perform lighting operations, and othertransformations upon graphics data. Vertex and pixel shaders are twotypes of procedural shaders that are currently implemented inspecialized graphics ICs.

With current 3D APIs, the API does not provide packaged operations to beperformed in connection with procedural shaders, such as vertex andpixel shaders. Invariably, a developer designs these procedural shaderalgorithms from scratch for each application. While there may be somecrossover from application to application, the bottom line is that adeveloper has to implement these algorithms each time for a newapplication. Thus, while the core commands for use with the proceduralshaders are available to the developer, the effective or efficientcombination of those commands is left to the developer. Consequently,algorithms that are unique, common and useful in connection with typical3D graphics processes, such as algorithms that are typically used inconnection with procedural shaders, are designed from the ground up foreach application. Conceptually, these elements for acting on proceduralshaders have been customized by necessity and thus provided ‘above’ theAPI. With present procedural shader hardware designs, for example, aspecialized set of assembly language instructions has been developed,which in part replaces or duplicates some of the custom coding currentlyimplemented by the developer. However, there is no mechanism thatexposes to the developer unique algorithmic elements for use withprocedural shaders via a mechanism that is conceptually below or insidethe software interface.

As is apparent from the above, advances in hardware and graphicsalgorithms have been revolutionizing the way graphics platforms operate.Generally speaking, however, current 3D graphics chips on the market arerigid in design and have very little flexibility in terms of theiroperation diversity. For example, while they provide high performancefor certain operations, current chips do not necessarily have theflexibility to alter their operation via software. While EEPROMtechnology and the like has existed for sometime where the operation ofa chip can be programmably reset, the logic of graphics chips has beentypically preset at the factory. However, there are innumerablecircumstances where it is desirable to take operations previouslycustomized by a developer for an application, and make these operationsdownloadable to a 3D chip for improved performance characteristics. Ascutting edge 3D graphics chips, still being designed in some cases, havebegun to handle such programmable functionality, by including flexibleon chip processing and limited on chip memory, to remove custom graphicscode from the processing of the host processor and to place suchprogrammable and downloadable functionality in a graphics chip would beof key importance in future graphics platforms. Thus, there is a needfor an API that provides this ability to have a programmable 3D chip,wherein programming or algorithmic elements written by the developer canbe downloaded to the chip, thereby programming the chip to perform thosealgorithms at improved performance levels. Related to this case where adeveloper may write a routine downloadable to the 3D chip, there arealso a set of algorithmic elements that are provided in connection withthe 3D API (routines that are not written by the developer, but whichhave already been programmed for the developer). Similarly, it would bedesirable to be able to download these API algorithms to a programmable3D chip for improved performance. It would thus be advantageous to havethe ability to download 3D algorithmic elements to provide improvedperformance, greater control as well as development ease.

While 3D graphics chips are currently undergoing improvements, there arealso improvements taking place on the display side of the API i.e., oncedata has been processed, the API facilitates the transfer of graphicsdata to the rasterizer. The rasterizer is a specialized displayprocessor chip that, among other things, converts digital pixel datainto an analog form appropriate for a display device, such as a monitor.While direct video memory access was previously a possibility, it is nolonger a possibility, due to faster techniques employing specializedhardware. Currently, specialized or private drivers and surface formatsare used in connection with very fast graphics accelerators. With directrasterizer/processor access to display memory surfaces, “chunks” ofsurfaces can be moved around according to the specialized surfaceformat, and pulled for processing as efficiency dictates. Thus, thepipeline between display memory surface space and the display itself hasbeen made more efficient, but there currently is no mechanism that makesthese direct rasterizer/processor memory access techniques seamless tothe application developers via a graphics API whose applicationsultimately benefit from the efficiencies of display surface data chunkmanipulation.

Thus, as a consequence, the graphics APIs used as the layer thatinsulates game developers from the details of these changes also need tobe changed to be in line with the changes in hardware. When implementedefficiently, these changes can create noticeable differences in the easeand robustness with which APIs may be used by game or other graphicsdevelopers. Additionally, the advances in hardware create an opportunityto simplify some processes by increasing maintainability, decreasingmemory consumption and providing greater usability of the 3D renderingand processing pipeline.

It would be advantageous to provide an optimization that allows adeveloper coding an application to specify the transmission of multipledata objects, wherever originated or located at the time of operation,to a 3D chip simultaneously or in parallel. Because graphics ICs haveevolved to possess functionality wherein data objects can be processedin parallel, it would be desirable to expose this functionality todevelopers, thereby allowing developers to specify multiple data objectsupon which operations are to be performed simultaneously.

In view of the above problems, it would be beneficial to prevent theseverance of connections between surfaces and objects when multipleapplications maintain connections to surface memory space. It would bedesirable to unify existing API command structures into concrete, atomicalgorithmic elements to enable greater development ease. It would beadvantageous to be able to automatically transition data objects betweenmemory types to enable the seamless switching of data. It would befurther beneficial to be able to feed graphics data objects in parallelto a 3D chip for processing. It would be further advantageous to havethe ability to download 3D algorithmic elements to a 3D graphics chip.It would be still further beneficial to make today's directrasterizer/processor memory access techniques seamless to theapplication developers via a graphics API. It would be yet furtheradvantageous to leverage the algorithmic components used for proceduralshader operations provided by today's procedural shaders by exposing thecomponents to the developer via the software interface.

SUMMARY OF THE INVENTION

In view of the foregoing, the present invention provides a method andsystem for controlling the algorithmic elements in 3D graphics systemsvia an improved 3D graphics API. More particularly, the presentinvention is directed to an API that enables programmability of a 3Dchip, wherein programming or algorithmic elements written by a developercan be downloaded to the chip, thereby programming the chip to performthose algorithms.

According to aspects of the invention, 3D algorithmic elements writtenby a developer can be downloaded to the 3D chip for improved performancecharacteristics. A developer writes a routine that may be downloaded tothe 3D graphics chip. There are also a set of algorithmic elements thatare provided in connection with the API of the present invention(routines that do not have to be written by developer, but which havealready been programmed for the developer), that are downloadable to theprogrammable chip for improved performance. A developer may downloadpreexisting API objects to the 3D graphics chip.

In an exemplary embodiment of the present invention, a developer adheresto a specific format for packing up an algorithmic element, or set ofinstructions, for implementation by a 3D graphics chip. The developerpacks the instruction set into an array of numbers, by referring to alist of ‘tokens’ understood by the 3D graphics chip. This array ofnumbers in turn is mapped correctly to the 3D graphics chip forimplementation of the algorithmic element by the 3D graphics chip.

According to another embodiment of the present invention, a specializedset of instructions, or list of tokens packed as an array of numbers,can be combined in such ways as to create useful algorithmic elements.The present invention takes these useful combinations and exposes thealgorithmic elements to the developer by way of the API. Conceptually,therefore, the present invention provides these useful algorithmicelements for acting on procedural shaders below or inside the API. Thepresent invention provides API objects, which are useful combinations ofa procedural shader's instruction set for acting upon the shader. Inthis fashion, algorithmic elements for use with a procedural shader areexposed to the developer.

Other features of the present invention are described below.

BRIEF DESCRIPTION OF THE DRAWINGS

The system and methods for controlling the 3D algorithmic elements in a3D computer graphics system are further described with reference to theaccompanying drawings in which:

FIG. 1 is a block diagram representing a suitable computing systemenvironment in which the present invention may be implemented;

FIG. 2 is a block diagram representing an exemplary network environmentin which the present invention may be implemented;

FIG. 3A is a block diagram illustrating various connections betweensurfaces and objects in a graphics system running multiple applicationssimultaneously, wherein a connection may be lost;

FIG. 3B is a block diagram illustrating various connections betweensurfaces and objects in a graphics system running multiple applicationssimultaneously wherein the connections are preserved according to thepresent invention;

FIG. 4A illustrates the unification of 2D and 3D graphics APIs inaccordance with the present invention;

FIG. 4B illustrates various ways in which applications could perform atexture download in accordance with prior 3D graphics APIs;

FIG. 4C illustrates a single way in which applications perform a texturedownload in accordance with the 3D graphics API of the presentinvention;

FIG. 4D illustrates various ways in which applications could perform aresolution change in accordance with prior 3D graphics APIs;

FIG. 4E illustrates a single function by which applications perform aresolution change in accordance with the 3D graphics API of the presentinvention;

FIG. 5 illustrates the downloading of specialized graphics functions toa 3D graphics chip in accordance with the 3D graphics API of the presentinvention;

FIG. 6A illustrates prior art techniques of interacting with proceduralshaders;

FIG. 6B illustrates techniques of communicating with procedural shadersin accordance with the 3D graphics API of the present invention;

FIG. 7A illustrates a private driving format in connection with whichthe 3D graphics API of the present invention may be implemented;

FIG. 7B illustrates the 3D graphics API of the present invention thatoperates seamlessly with respect to the private driving format of FIG.7A;

FIG. 8A illustrates a prior art technique of switching data among memorytypes with previous graphics APIs;

FIG. 8B illustrates the automatic switching of data among memory typesin a graphics system in accordance with a cache managing algorithm ofthe 3D graphics API of the present invention;

FIG. 9A illustrates a prior art technique whereby data is transmitted toa graphics chip serially; and

FIG. 9B illustrates a technique in accordance with the 3D graphics APIof the present invention whereby data is transmitted to a graphics chipin parallel.

DETAILED DESCRIPTION OF ILLUSTRATIVE EMBODIMENTS Overview

The present invention provides a new and improved API as a layer betweenapplication developers and the current state of the art of graphicshardware and the pipeline that renders and processes the graphics data.An API is provided that enables programmability of a 3D chip, whereinprogramming or algorithmic elements written by the developer can bedownloaded to the chip, thereby programming the chip to perform thosealgorithms. A developer writes a routine that is downloadable to a 3Dgraphics chip. There are also a set of algorithmic elements that areprovided in connection with the API that have already been programmedfor the developer, that are downloadable to the programmable chip forimproved performance. Thus, a developer may download preexisting APIobjects to a 3D graphics chip. A developer adheres to a specific formatfor packing up an algorithmic element, or set of instructions, forimplementation by a 3D graphics chip. The developer packs theinstruction set into an array of numbers, by referring to a list of‘tokens’ understood by the 3D graphics chip. This array of numbers inturn is mapped correctly to the 3D graphics chip for implementation ofthe algorithmic element by the 3D graphics chip.

Exemplary Computer and Network Environments

FIG. 1 and the following discussion are intended to provide a briefgeneral description of a suitable computing environment in which theinvention may be implemented. Although not required, the invention willbe described in the general context of computer-executable instructions,such as program modules, being executed by one or more computers, suchas client workstations, servers or other devices. Generally, programmodules include routines, programs, objects, components, data structuresand the like that perform particular tasks or implement particularabstract data types. Typically, the functionality of the program modulesmay be combined or distributed as desired in various embodiments.Moreover, those skilled in the art will appreciate that the inventionmay be practiced with other computer system configurations. Other wellknown computing systems, environments, and/or configurations that may besuitable for use with the invention include, but are not limited to,personal computers (PCs), server computers, hand-held or laptop devices,multi-processor systems, microprocessor-based systems, programmableconsumer electronics, network PCs, minicomputers, mainframe computers,gaming platforms and the like. The invention may also be practiced indistributed computing environments where tasks are performed by remoteprocessing devices that are linked through a communications network orother data transmission medium. In a distributed computing environment,program modules may be located in both local and remote computer storagemedia including memory storage devices.

FIG. 1 illustrates an example of a suitable computing system environment100 in which the invention may be implemented. The computing systemenvironment 100 is only one example of a suitable computing environmentand is not intended to suggest any limitation as to the scope of use orfunctionality of the invention. For example, graphics applicationprogramming interfaces may be useful in a wide range of platforms.Neither should the computing environment 100 be interpreted as havingany dependency or requirement relating to any one or combination ofcomponents illustrated in the exemplary operating environment 100.

With reference to FIG. 1, an exemplary system for implementing theinvention includes a general purpose computing device in the form of acomputer 110. Components of computer 110 may include, but are notlimited to, a processing unit 120, a system memory 130, and a system bus121 that couples various system components including the system memoryto the processing unit 120. The system bus 121 may be any of severaltypes of bus structures including a memory bus or memory controller, aperipheral bus, and a local bus using any of a variety of busarchitectures. By way of example, and not limitation, such architecturesinclude Industry Standard Architecture (ISA) bus, Micro ChannelArchitecture (MCA) bus, Enhanced ISA (EISA) bus, Video ElectronicsStandards Association (VESA) local bus, and Peripheral ComponentInterconnect (PCI) bus (also known as Mezzanine bus).

Computer 110 typically includes a variety of computer readable media.Computer readable media can be any available media that can be accessedby computer 110 and includes both volatile and nonvolatile media,removable and non-removable media. By way of example, and notlimitation, computer readable media may comprise computer storage mediaand communication media. Computer storage media includes both volatileand nonvolatile, removable and non-removable media implemented in anymethod or technology for storage of information such as computerreadable instructions, data structures, program modules or other data.Computer storage media includes, but is not limited to, RAM, ROM,EEPROM, flash memory or other memory technology, CDROM, digitalversatile disks (DVD) or other optical disk storage, magnetic cassettes,magnetic tape, magnetic disk storage or other magnetic storage devices,or any other medium which can be used to store the desired informationand which can accessed by computer 110. Communication media typicallyembodies computer readable instructions, data structures, programmodules or other data in a modulated data signal such as a carrier waveor other transport mechanism and includes any information deliverymedia. The term “modulated data signal” means a signal that has one ormore of its characteristics set or changed in such a manner as to encodeinformation in the signal. By way of example, and not limitation,communication media includes wired media such as a wired network ordirect-wired connection, and wireless media such as acoustic, RF,infrared and other wireless media. Combinations of any of the aboveshould also be included within the scope of computer readable media.

The system memory 130 includes computer storage media in the form ofvolatile and/or nonvolatile memory such as read only memory (ROM) 131and random access memory (RAM) 132. A basic input/output system 133(BIOS), containing the basic routines that help to transfer informationbetween elements within computer 110, such as during start-up, istypically stored in ROM 131. RAM 132 typically contains data and/orprogram modules that are immediately accessible to and/or presentlybeing operated on by processing unit 120. By way of example, and notlimitation, FIG. 1 illustrates operating system 134, applicationprograms 135, other program modules 136, and program data 137.

The computer 110 may also include other removable/non-removable,volatile/nonvolatile computer storage media. By way of example only,FIG. 1 illustrates a hard disk drive 141 that reads from or writes tonon-removable, nonvolatile magnetic media, a magnetic disk drive 151that reads from or writes to a removable, nonvolatile magnetic disk 152,and an optical disk drive 155 that reads from or writes to a removable,nonvolatile optical disk 156, such as a CD ROM or other optical media.Other removable/non-removable, volatile/nonvolatile computer storagemedia that can be used in the exemplary operating environment include,but are not limited to, magnetic tape cassettes, flash memory cards,digital versatile disks, digital video tape, solid state RAM, solidstate ROM, and the like. The hard disk drive 141 is typically connectedto the system bus 121 through an non-removable memory interface such asinterface 140, and magnetic disk drive 151 and optical disk drive 155are typically connected to the system bus 121 by a removable memoryinterface, such as interface 150.

The drives and their associated computer storage media discussed aboveand illustrated in FIG. 1, provide storage of computer readableinstructions, data structures, program modules and other data for thecomputer 110. In FIG. 1, for example, hard disk drive 141 is illustratedas storing operating system 144, application programs 145, other programmodules 146, and program data 147. Note that these components can eitherbe the same as or different from operating system 134, applicationprograms 135, other program modules 136, and program data 137. Operatingsystem 144, application programs 145, other program modules 146, andprogram data 147 are given different numbers here to illustrate that, ata minimum, they are different copies. A user may enter commands andinformation into the computer 110 through input devices such as akeyboard 162 and pointing device 161, commonly referred to as a mouse,trackball or touch pad. Other input devices (not shown) may include amicrophone, joystick, game pad, satellite dish, scanner, or the like.These and other input devices are often connected to the processing unit120 through a user input interface 160 that is coupled to the system bus121, but may be connected by other interface and bus structures, such asa parallel port, game port or a universal serial bus (USB). A monitor191 or other type of display device is also connected to the system bus121 via an interface, such as a video interface 190. In addition to themonitor, computers may also include other peripheral output devices suchas speakers 197 and printer 196, which may be connected through anoutput peripheral interface 195.

The computer 110 may operate in a networked environment using logicalconnections to one or more remote computers, such as a remote computer180. The remote computer 180 may be a personal computer, a server, arouter, a network PC, a peer device or other common network node, andtypically includes many or all of the elements described above relativeto the computer 110, although only a memory storage device 181 has beenillustrated in FIG. 1. The logical connections depicted in FIG. 1include a local area network (LAN) 171 and a wide area network (WAN)173, but may also include other networks. Such networking environmentsare commonplace in offices, enterprise-wide computer networks, intranetsand the Internet.

When used in a LAN networking environment, the computer 110 is connectedto the LAN 171 through a network interface or adapter 170. When used ina WAN networking environment, the computer 110 typically includes amodem 172 or other means for establishing communications over the WAN173, such as the Internet. The modem 172, which may be internal orexternal, may be connected to the system bus 121 via the user inputinterface 160, or other appropriate mechanism. In a networkedenvironment, program modules depicted relative to the computer 110, orportions thereof, may be stored in the remote memory storage device. Byway of example, and not limitation, FIG. 1 illustrates remoteapplication programs 185 as residing on memory device 181. It will beappreciated that the network connections shown are exemplary and othermeans of establishing a communications link between the computers may beused.

As mentioned, a computer, such as described above, can be deployed aspart of a computer network. Further, the present invention pertains toany computer system having any number of memory or storage units, andany number of applications and processes occurring across any number ofstorage units or volumes. Thus, the present invention may apply to bothserver computers and client computers deployed in a network environment,having remote or local storage. More and more, graphics applications arebecoming deployed in network environments. FIG. 2 thus illustrates anexemplary network environment, with a server in communication withclient computers via a network, in which the present invention may beemployed. As shown, a number of servers 10 a, 10 b, etc., areinterconnected via a communications network 14 (which may be a LAN, WAN,intranet or the Internet) with a number of client computers 110 a, 110b, 110 c, etc. In a network environment in which the communicationsnetwork 14 is the Internet, for example, servers 10 can be Web serverswith which the clients 110 a, 110 b, etc. communicate via any of anumber of known protocols such as hypertext transfer protocol (HTTP).The invention may also leverage peer to peer networking techniques. Eachclient computer 110 and server computer 10 may be equipped with variousapplication program modules 135, other program modules 136 and programdata 137, and with connections or access to various types of storageelements or objects, across which files may be stored or to whichportion(s) of files may be downloaded or migrated. Each client computer110 and server computer 10 may also be connected to additional storageelements 20, such as a database. Thus, the present invention can beutilized in a computer network environment having client computers foraccessing and interacting with a network and server computers 10 a, 10b, etc. for interacting with client computers.

Maintenance of Connection between Surfaces and Objects

As mentioned in the background, a resource contention issue sometimesoccurs due to the demands of multiple devices and applications requiringgraphics system resources simultaneously. Current 3D graphics APIssometimes improperly manage resources such that if multiple applicationsrunning simultaneously are maintaining connections to multiple surfacesfrom various objects of the graphics system, sometimes these connectionsto surfaces can become severed or disconnected. If the connection tosurface memory for any one application is severed, a user may have torestart the application or begin certain portions of the applicationagain in order to recreate a proper connection.

FIG. 3A illustrates some elementary components of a 3D graphics system.A rasterizer 310 processes graphics data from surface memory 320 inpreparation for its transmission to a display device having displaymemory 300. Any number of objects 330 a, 330 b to 330 n may be createdthrough graphics API 340 when applications 350 a and 350 b or more arerunning. Objects 330 a, 330 b to 330 n may be part of the graphics API340 or may be provided separately for use with the graphics system. AsFIG. 3A illustrates, a connection between surface space 320 and, forexample, object 330 b may become severed due to improper maintenance ofsystem resources when performing thousands of high speed operations formultiple applications. For example, some objects are responsible forbuilding and moving frames to surface space. Over the course ofoperation of a graphics application, thousands and thousands of suchbuild and move operations may take place. Presently, there is only onepoint in the API code that performs a ‘check’ to see if the connectionis properly maintained to achieve such operations. Previously, duringthe course of building, processing and presenting frame data, multiplechecks were performed, essentially each time any operation occurred withrespect to the data. This, however, is wasteful of computing resourcesin the event that a connection is lost since each check consumescomputing resources on its own.

In accordance with the present invention, by performing a check andmonitoring connections and system resources each time a frame ispresented, the consumption of valuable resources between presentoperations according to various operations is avoided. As shown in FIG.3B, the connection between surface 320 b and object 330 b is treated asif it persists between present operations in accordance with the presentinvention, even where the connection has been lost. For example, where atypical check for the persistence of the connection between surfaces andobjects includes returning a flag, such as true or false, depending uponthe whether the connection persists, these operations may be skipped orspoofed such that between present operations, the flag continues toindicate that the connection persists, even if it has been lost, thusavoiding multiple, redundant checks for the persistence of theconnection. As a result, operations are streamlined between presentcalls such that checks are made when expedient to do so. Thus, thepresent invention prevents wasteful consumption of computing resourcesdue to the loss of connection between surfaces and objects when multipledevices and applications demand premium system resources simultaneously.

In an exemplary embodiment, the present invention provides a solution byunifying the command structure that previously checked for lostconnections to surfaces. Previously, there were innumerable places wherethe application checked for and handled resource issues between presentcalls. This distributed the checkpoints and created multiple, if nothundreds or thousands of places throughout the application where checksoccurred between present calls, creating inefficiencies and furtheropportunities for error due to wasteful devotion of computing resources.In accordance with the present invention, each time data is ‘presented’to the surface memory space 320 according to a ‘present’ function call,the 3D API of the invention checks for these resource contention issues.Thus, instead of having many different cases occurring at differenttimes for which the API might determine that a connection has been lost,the 3D API of the invention checks each time a ‘present’ function callis made, thereby providing a single case for a lost connection such thatresources may be newly allocated according to the same unifiedprocedure. This check may be performed before or after the present call,or included therein. It can be appreciated that any call, such as apresent function call, that is cyclical and occurs once per frame e.g.,at a typical 30 or 60 frames per second, or other recurring event mayalso be utilized to achieve the above goals.

Unification of Previous API Command Structure into Concrete AlgorithmicElements

The subsequent versioning of a software product to meet the needs of anevolving operating environment sometimes results in inefficiencieswherein once separate or merely related modules may be more efficientlyplaced together, rewritten or merged. Thus, the present inventionunifies existing API command structures into concrete, atomicalgorithmic elements that ease the task of development.

For example, while the creation, processing and rendering of 3D objectsby a 3D API utilizes algorithms and function calls of the 2D API, asingle set of APIs does not exist for the purpose of creating both 2Dand 3D objects. There are thus typically multiple choices for adeveloper to make, when creating, processing or rendering an object,which makes the developer's work more complex. For example, withreference to FIG. 4A, there are numerous instances where the current 2Dgraphics API shares functionality with the current 3D graphics API,because, for example, both include the same function calls. There arealso instances wherein to perform a function 410 a with the 3D graphicsAPI 410 may involve a function call to function 400 a of the 2D graphicsAPI, and vice versa. While the overlap in the figure is illustratedsimply with dashed lines, the reality of current interoperation is farfrom simple, and leaves the developer with too many choices. The presentinvention thus provides a single 2D and 3D graphics API, providing aunified programming body with which developers may work.

Currently, there are no 3D graphics APIs that unify 2D and 3D graphicsdata types. Historically, due to the evolution of 2D and 3D graphicsprocessing, with ‘modern’ 2D graphics applications beginning as early asthe 1970s and with 3D graphics applications developing in parallelfashion at a later time, 2D and 3D data types have simply been treateddifferently by different applications i.e., memory allocation, memorystructures and memory management have been different as between 2D and3D data types. Thus, because the present invention unifies data typesand choices with respect to 2D and 3D data types, memory managementtechniques have been unified in accordance with the present invention,eliminating ad hoc memory management based on whether the data was a 2Ddata type or a 3D data type. Due to the unification of 2D and 3D dataformatting, the definition of data is simplified from the perspective ofthe developer. Thus, a long felt need in the art for a unified 2D and 3DAPI is addressed by the present invention.

In the above scenario, there is an overlapping of functionality amongAPI objects that is not exploited. There are also other instances inwhich the number of choices available to developers for the same orsimilar functionality can both complicate the development process andcreate a source of inefficiency. For instance, there are three ways fora developer to perform a texture download depending upon the hardwareinvolved, wherein data is transferred from a system memory surface to a3D display memory surface. Textures are rectangular arrays of coloredpixels, which tend to be square in graphics applications, and whenprocessed in quantity, represent a lot of data. A texture download, inthis regard, is important because ultimately slow texture downloadingcan become a bottleneck in graphics data processing. Different texturedownloads, depending upon the hardware used incident thereto, havedifferent data transfer rates associated therewith and thus the choiceof texture download made by the developer can affect the overall systemperformance. The optimization of this data transfer rate, if required ofthe developer, can involve considerable time, effort and skill.

As illustrated in FIG. 4B, three different functions or ways 340 a, 340b and 340 c of graphics API 340 are currently available to a developerfor use in connection with a texture download depending upon whichhardware 430 a, 430 b . . . 430 n is involved. When multiple hardware430 a, 430 b . . . 430 n is present, and a developer has three choicesto make regarding texture downloading data from a system memory surface440 a, 440 b . . . 440 n to 3D display memory surface 450, the decisionis undesirably time-consuming, complex and requires an understanding ofthe underlying hardware in order to make efficient decisions. Thepresent invention thus provides a single fast texture download. Insteadof having a plurality of mappings from an application to API objects,and multiple commands that perform the same or similar actions, thepresent invention provides a single mapping. The present invention thuscentralizes the diversity of current texture downloads and provides aunified singular command structure, thereby reducing the number ofdiverse, and redundant, mappings to API texture downloads. Instead ofchoosing among API objects 340 a, 340 b or 340 c of FIG. 4B, or acombination thereof, or having to write an optimization routine thatoptimizes the use of 340 a, 340 b or 340 c, the present inventionprovides a single texture download object 340_td for use by thedeveloper, as shown in FIG. 4C.

Optimization of graphics components used incident to a texture download,such as hardware 430 a, 430 b, . . . 430 n, is thus performed by the APIobject 340_td in accordance with the present invention, thereby freeingthe developer to be concerned with other aspects of the graphicsapplication. For example, according to one optimization, the number oftimes used and order of hardware components 430 a, 430 b, etc. utilizedin connection with a texture download is hidden from the developer. Forexample, in one embodiment, object 340_td keeps track of how well thehardware objects 430 a, 430 b, etc. are keeping up in terms of freememory (capacity) and speed of data processing and transfer. This may beconfigured staticly beforehand, so as to control the number and order ofhardware components 430 a, 430 b, etc. that may be used and inconnection with a texture download, or this may be performed dynamicallybased upon an evaluation of the performance of texture downloading, withfeedback from the hardware components 430 a, 430 b, etc.

In addition, there are a number of instances in which existing 3Dgraphics APIs inconvenience the developer by requiring the developer towrite substantially more complex code than is necessary in view oftoday's computing environments. For example, currently it requires atleast five programming steps to effect a resolution change,inconveniencing the developer each time a resolution change is desired.While coding five steps is still better than interfacing directly withgraphics system components, the present invention unifies the commandstructure of a resolution change, allowing a developer to effect aresolution change with a single API command. The present invention thusprovides a single command to effect a resolution change, insulating thedeveloper from the detailed changes that are made in the graphics systemin order to effect the change. This is yet another example where currentgraphics APIs require the developer to have an overly detailedunderstanding of the underlying graphics hardware. As shown in FIG. 4D,there are currently five steps or commands 340 _(—) rc 1, 340 _(—) rc 2,340 _(—) rc 3, 340 _(—) rc 4 and 340 _(—) rc 5 that a developer D1 mustenter in order to effect a graphics system resolution change RC. Each ofcommands 340 _(—) rc 1, 340 _(—) rc 2, 340 _(—) rc 3, 340 _(—) rc 4 and340 _(—) rc 5 has an independent bearing on the graphics system whichcan involve overlapping functionality or redundant arguments. Thus, asFIG. 4E illustrates, the present invention provides a single efficientAPI object 340 _(—) rc to achieve a resolution change. Thus, in theseand other instances, the present invention unifies existing API commandstructures into concrete, atomic algorithmic elements that ease the taskof development for a developer.

Downloading of 3D Algorithmic Elements to 3D Chip and Unique AlgorithmicElements for Use with Procedural Shaders

The API of the present invention enables programmability of a 3D chip,wherein programming or algorithmic elements written by the developer canbe downloaded to the chip, thereby programming the chip to perform thosealgorithms.

Thus far, the functionality of 3D hardware chips or components has beenrelatively fixed from the vantage point of the developer, leaving littleflexibility at the developer end to perform efficient sets of operationsthat are tailored to an application or that allow the developer tocontrol the algorithmic elements that are performed by the 3D graphicschip. There are innumerable circumstances where the state of the art ofgraphics hardware has made it desirable to take operations previouslycustomized by a developer for an application, and make these operationsdownloadable to a 3D chip for improved performance characteristics.Since 3D graphics chips have evolved to be very high performancecompared to host system processing space, it would be advantageous toallow a developer to download functionality to the 3D chip.

Thus, by way of the API of the present invention, 3D algorithmicelements written by a developer can be downloaded to the 3D chip forimproved performance characteristics. FIG. 5 illustrates this processwhereby a developer D1 writes a routine 500 that may be downloaded to 3Dgraphics chip 510. Similar to this case where a developer may write aroutine 500 downloadable to the 3D chip 510, there are also a set ofalgorithmic elements that are provided in connection with the API of thepresent invention (routines that do not have to be written by developerD1, but which have already been programmed for the developer D1), thatare downloadable to the programmable chip 510 for improved performance.As shown in FIG. 5, a developer D1 may download preexisting API objects340 a, 340 b, . . . 340 n to 3D graphics chip 510. While graphicsapplications generally involve a performance specification that includesfast processing and fast rendering, the ability to control 3Dalgorithmic elements in this fashion is very advantageous, because itallows a developer access to the fastest, highest performance portionsof the graphics processing system, enabling the developer to downloadefficient algorithmic elements to the graphics chip 510 that aretailored to the application at hand.

In an exemplary embodiment, a developer adheres to a specific format forpacking up an algorithmic element, or set of instructions, forimplementation by a 3D graphics chip. The developer packs theinstruction set into an array of numbers, by referring to a list of‘tokens’ understood by the 3D graphics chip. This array of numbers inturn is mapped correctly to the 3D graphics chip for implementation ofthe algorithmic element by the 3D graphics chip. Further background,hereby incorporated by reference in its entirety, may be found in U.S.Pat. No. 6,819,325 entitled “API Communications For Vertex And PixelShaders” having inventors Boyd and Toelle.

With respect to unique algorithmic elements for use with proceduralshaders in accordance with the present invention, some generalbackground is instructive: rendering and displaying three dimensionalgraphics typically involves many calculations and computations. Forexample, to render a three dimensional object, a set of coordinatepoints or vertices that define the object to be rendered must be formed.Vertices can be joined to form polygons that define the surface of theobject to be rendered and displayed. Once the vertices that define anobject are formed, the vertices are transformed from an object or modelframe of reference to a world frame of reference and finally to twodimensional coordinates that can be displayed on a flat display device.Along the way, vertices may be rotated, scaled, eliminated or clippedbecause they fall outside the viewable area, are lit by various lightingschemes, colorized, and so forth. Thus, the process of rendering anddisplaying a three dimensional object can be computationally intensiveand may involve a large number of vertices.

A triangle has many helpful properties that make it ideal for use inrendering three dimensional surfaces. A triangle is completely definedby three vertices and a triangle also uniquely defines a plane. Thus,many systems will use a plurality of triangles to render a threedimensional surface. If each triangle is passed separately to thegraphic subsystem that renders the three dimensional object, then threevertices for each triangle must be passed and processed by the graphicsubsystem. However, the number of vertices that must be passed andprocessed by the graphic subsystem can be reduced through “vertexsharing.” Vertex sharing relies on a property of shared sides amongtriangles. Although it takes three vertices to define one triangle, itonly takes four vertices to define two triangles if they share a commonside. In order to take advantage of vertex sharing to reduce the numberof vertices needed to render an object, pipelined systems have beendeveloped that divide a three dimensional object into triangle stripsthat can then be processed and displayed efficiently.

Indeed, specialized 3D software objects and/or hardware components suchas procedural shaders have been created or designed for the purpose ofcarrying out specialized graphics functionality upon graphics data, inorder to speed the process of rendering complex graphics objects.Procedural shaders, such as vertex and pixel shaders, have traditionallybeen used to perform such complex transformations on pixels and/orarrays of pixels or triangles.

However, the functionality of these procedural shading software objectsor hardware components has been relatively fixed, leaving littleflexibility at the developer end to perform efficient sets of operationsthat may be efficiently tailored to a particular graphics application ortask.

Thus, with previous 3D APIs, the API did not provide the developer withflexibility as to operations that could be performed in connection withprocedural shaders, such as vertex and pixel shaders. Vertex and pixelshaders, which may be implemented with software or in hardware or with acombination of both, have specialized functionality. Currently, in orderto utilize useful algorithmic elements of a procedural shader, orotherwise use fixed and limited functionality of the procedural shader,a developer has to invariably design software procedural shaderalgorithms from scratch for each application. While the core commandsfor use with the procedural shaders were available to the developer, theeffective or efficient combination of these commands is left to thedeveloper. Consequently, algorithms that are unique, common and usefulin connection with typical 3D graphics processes, such as for typicaluse in connection with procedural shaders, are developed from the groundup for each application. Conceptually, these elements for acting onprocedural shaders have been customized by necessity for eachapplication and thus provided ‘above’ the API, programmed as part of thegraphics application itself. As shown in FIG. 6A, developer D1, withaccess to a specification for a procedural shader 610, programs aninflexible object 600 so as to work with or control the proceduralshader 610. As FIG. 6A illustrates, developer D1 develops a shadingalgorithm with code. After customization by the developer D1, object 600interacts with shader(s) 610 via graphics API 340.

With present hardware designs of procedural shaders, however, aspecialized set of assembly language instructions has been developedcreating flexibility of procedural shader use. The developer still hasaccess to the specialized set of instructions as in the past.Advantageously, with the present invention, this specialized set ofinstructions, or list of tokens packed as an array of numbers, can becombined in such ways as to create useful algorithmic elements. Thepresent invention takes these useful combinations and exposes thealgorithmic elements to the developer by way of the API 340.Conceptually, therefore, the present invention provides these usefulalgorithmic elements for acting on procedural shaders below or insidethe API. As FIG. 6B illustrates, the present invention provides APIobjects 340 _(—) ps 1, 340 _(—) s 2, . . . 340 _(—) psn, which areuseful combinations of procedural shader 610's instruction set foracting upon shader 610. In this fashion, algorithmic elements for usewith procedural shader 610 are exposed to the developer D1.

For more concrete examples of algorithmic elements that used to becustomized by necessity above the API, which are now provided for usebelow are any of the following types of techniques, taken alone or incombination: lighting, colorizing, mapping, texturizing, surfacing,shading, enhancing, and other image processing techniques.

Some exemplary code or definitional pseudocode for a procedural shader,such as a vertex shader, is provided below. The declaration portion ofan exemplary procedural shader defines the static external interface ofthe procedural shader. The information in the declaration includesassignments of vertex shader input registers to data streams. Theseassignments bind a specific vertex register to a single component withina vertex stream. A vertex stream element is identified by a byte offsetwithin the stream and a type. The type specifies the arithmetic datatype plus the dimensionality (1, 2, 3, or 4 values). Stream data that isless than four values are preferably expanded out to four values withzero or more 0.F values and one 1.F value.

The information in the declaration also includes assignment of vertexshader input registers to implicit data from the primitive tessellator.This controls the loading of vertex data which is not loaded from astream, but rather is generated during primitive tessellation prior tothe vertex shader.

Moreover, the information in the declaration also includes loading datainto the constant memory at the time a procedural shader is set as thecurrent procedural shader. Each token specifies values for one or morecontiguous 4 DWORD constant registers. This allows the procedural shaderto update an arbitrary subset of the constant memory, overwriting thedevice state (which contains the current values of the constant memory).Note that these values can be subsequently overwritten (betweenDrawPrimitive calls) during the time a procedural shader is bound to adevice via the SetVertexShaderConstant method.

Declaration arrays are single-dimensional arrays of DWORDs composed ofmultiple tokens each of which is one or more DWORDs. The single DWORDtoken value 0xFFFFFFFF is a special token used to indicate the end ofthe declaration array. The single DWORD token value 0x00000000 is a NOPtoken with is ignored during the declaration parsing. Note that0x00000000 is a valid value for DWORDs following the first DWORD formultiple word tokens.

[31:29] TokenType

-   -   0x0—NOP (requires all DWORD bits to be zero)    -   0x1—stream selector    -   0x2—stream data definition (map to vertex input memory)    -   0x3—vertex input memory from tessellator    -   0x4—constant memory from shader    -   0x5—extension    -   0x6—reserved    -   0x7—end-of-array (requires all DWORD bits to be 1).        NOP Token (Single DWORD Token)    -   [31:29] 0x0    -   [28:00] 0x0.        Stream Selector (Single DWORD Token)    -   [31:29] 0x1    -   [28] indicates whether this is a tessellator stream    -   [27:04] 0x0    -   [03:00] stream selector (0.15).        Stream Data Definition (Single DWORD Token)    -   Vertex Input Register Load    -   [31:29] 0x2    -   [28] 0x0    -   [27:20] 0x0    -   [19:16] type (dimensionality and data type)    -   [15:04] 0x0    -   [03:00] vertex register address (0 . . . 15).        Data Skip (No Register Load)    -   [31:29] 0x2    -   [28] 0x1    -   [27:20] 0x0    -   [19:16] count of DWORDS to skip over (0 . . . 15)    -   [15:00] 0x0.        Vertex Input Memory from Tessellator Data (Single DWORD Token)    -   [31:29] 0x3    -   [28] indicates whether data is normals or u/v    -   [27:24] 0x0    -   [23:20] vertex register address (0 . . . 15)    -   [19:16] type (dimensionality)    -   [15:04] 0x0    -   [03:00] vertex register address (0 . . . 15).        Constant Memory from Shader (Multiple DWORD Token)    -   [31:29] 0x4    -   [28:25] count of 4*DWORD constants to load (0 . . . 15)    -   [24:07] 0x0    -   [06:00] constant memory address (0.95).        Extension Token (Single or Multiple DWORD Token)    -   [31:29] 0x5    -   [28:24] count of additional DWORDs in token (0.31)    -   [23:00] extension-specific information.        End-of-Array Token (Single DWORD Token)    -   [31:29] 0x7    -   [28:00] 0x1ffffff.

The stream selector token is desirably followed by a contiguous set ofstream data definition tokens. This token sequence fully defines thatstream, including the set of elements within the stream, the order inwhich the elements appear, the type of each element, and the vertexregister into which to load an element.

Streams are allowed to include data which is not loaded into a vertexregister, thus allowing data which is not used for this shader to existin the vertex stream. This skipped data is defined only by a count ofDWORDs to skip over, since the type information is irrelevant.

The token sequence:

-   Stream Select: stream=0-   Stream Data Definition (Load): type=FLOAT3; register=3-   Stream Data Definition (Load): type=FLOAT3; register=4-   Stream Data Definition (Skip): count=2-   Stream Data Definition (Load): type=FLOAT2; register=7.    defines stream zero to consist of four elements, three of which are    loaded into registers and the fourth skipped over. Register 3 is    loaded with the first three DWORDs in each vertex interpreted as    FLOAT data. Register 4 is loaded with the fourth, fifth, and sixth    DWORDs interpreted as FLOAT data. The next two DWORDs (seventh and    eighth) are skipped over and not loaded into any vertex input    register. Register 7 is loaded with the ninth and tenth DWORDS    interpreted as FLOAT data.

Placing of tokens other than NOPs between the Stream Selector and StreamData Definition tokens is disallowed.

-   typedef enum_D3DVSD_TOKENTYPE-   {    -   D3DVSD_TOKEN_NOP 0, // NOP or extension    -   D3DVSD_TOKEN_STREAM, // stream selector    -   D3DVSD_TOKEN_STREAMDATA, // stream data definition (map to        vertex input memory)    -   D3DVSD_TOKEN_TESSELLATOR, // vertex input memory from        tessellator    -   D3DVSD_TOKEN_CONSTMEM, // constant memory from shader    -   D3DVSD_TOKEN_EXT, // extension    -   D3DVSD_TOKEN_END 7, // end-of-array (requires all DWORD bits to        be 1)    -   D3DVSD_FORCE_DWORD 0x7fffffff, // force 32-bit size enum-   } D3DVSD_TOKENTYPE;-   #define D3DVSD_TOKENTYPESHIFT 29-   #define D3DVSD_TOKENTYPEMASK (7<<D3DVSD_TOKENTYPESHIFT)-   #define D3DVSD_STREAMNUMBERSHIFT 0-   #define D3DVSD_STREAMNUMBERMASK (0xF<<D3DVSD_STREAMNUMBERSHIFT)-   #define D3DVSD_DATALOADTYPESHIFT 28-   #define D3DVSD_DATALOADTYPEMASK (0x1<<D3DVSD_DATALOADTYPESHIFT)-   #define D3DVSD_DATATYPESHIFT 16-   #define D3DVSD_DATATYPEMASK (0xF<<D3DVSD_DATATYPESHIFT)-   #define D3DVSD_SKIPCOUNTSHIFT 16-   #define D3DVSD_SKIPCOUNTMASK (0xF<<D3DVSD_SKIPCOUNTSHIFT)-   #define D3DVSD_VERTEXREGSHIFT 0-   #define D3DVSD_VERTEXREGMASK (0x1F<<D3DVSD_VERTEXREGSHIFT)-   #define D3DVSD_VERTEXREGINSHIFT 20-   #define D3DVSD_VERTEXREGINMASK (0xF<<D3DVSD_VERTEXREGINSHIFT)-   #define D3DVSD_CONSTCOUNTSHIFT 25-   #define D3DVSD_CONSTCOUNTMASK (0xF<<D3DVSD_CONSTCOUNTSHIFT)-   #define D3DVSD_CONSTADDRESSSHIFT 0-   #define D3DVSD_CONSTADDRESSMASK (0x7F <<D3DVSD_CONSTADDRESSSHIIFT)-   #define D3DVSD_CONSTRSSHIFT 16-   #define D3DVSD_CONSTRSMASK (0x1FFF<<D3DVSD_CONSTRSSHIFT)-   #define D3DVSD_EXTCOUNTSHIFT 24-   #define D3DVSD_EXTCOUNTMASK (0x1F<<D3DVSD_EXTCOUNTSHIFT)-   #define D3DVSD_EXTINFOSHIFT 0-   #define D3DVSD_EXTINFOMASK (0xFFFFFF<<D3DVSD_EXTINFOSHIFT)-   #define D3DVSD_MAKETOKENTYPE(tokenType)    ((tokenType<<D3DVSD_TOKENTYPESHIFT) & D3DVSD_TOKENTYPEMASK)-   // macros for generation of CreateVertexShader Declaration token    array-   // Set current stream-   // _StreamNumber [0 . . . (MaxStreams−1)] stream to get data from-   //-   #define D3DVSD_STREAM(_StreamNumber)\    -   (D3DVSD_MAKETOKENTYPE(D3DVSD_TOKEN_STREAM)|(_StreamNumber))-   // Set tessellator stream-   //-   #define D3DVSD_STREAMTESSSHIFT 28-   #define D3DVSD_STREAMTESSMASK (1<<D3DVSD_STREAMTESSSHIFT)-   #define D3DVSD_STREAM_TESS( )\    -   (D3DVSD_MAKETOKENTYPE(D3DVSD_TOKEN_STREAM)|-   (D3DVSD_STREAMTESSMASK))-   // bind single vertex register to vertex element from vertex stream-   //-   // _VertexRegister [0 . . . 15] address of the vertex register-   // _Type [D3DVSDT_*] dimensionality and arithmetic data type-   #define D3DVSD_REG(_VertexRegister, _Type )\    -   (D3DVSD_MAKETOKENTYPE(D3DVSD_TOKEN_STREAMDATA)|\        -   ((_Type)<<D3DVSD_DATATYPESHIFT)|(_VertexRegister))-   // Skip _DWORDCount DWORDs in vertex-   //-   #define D3DVSD_SKIP(_DWORDCount)\    -   (D3DVSD_MAKETOKENTYPE(D3DVSD_TOKEN_STREAMDATA)|0x10000000|\        -   ((_DWORDCount)<<D3DVSD_SKIPCOUNTSHIFT))-   // load data into vertex shader constant memory-   //-   // _ConstantAddress [0 . . . 95]—address of constant array to begin    filling data-   // _Count [0 . . . 15]—number of constant vectors to load (4 DWORDs    each)-   // followed by 4*_Count DWORDS of data-   //-   #define D3DVSD_CONST(_ConstantAddress, _Count)\    -   (D3DVSD_MAKETOKENTYPE(D3DVSD_TOKEN_CONSTMEM)|\        -   ((_Count)<<D3DVSD_CONSTCOUNTSHIFT)|(_ConstantAddress))-   // enable tessellator generated normals-   //-   // _VertexRegisterIn [0 . . . 15] address of vertex register whose    input stream-   // will be used in normal computation-   // _VertexRegisterOut [0 . . . 15] address of vertex register to    output the normal to-   //-   #define D3DVSD_TESSNORMAL(_VertexRegisterIn, _VertexRegisterOut)\    -   (D3DVSD_MAKETOKENTYPE(D3DVSD_TOKEN_TESSELLATOR)|\        -   ((_VertexRegisterIn)<<D3DVSD_VERTEXREGINSHIFT)|\        -   ((0x02)<<D3DVSD_DATATYPESHIFT)|(_VertexRegisterOut))-   // enable tessellator generated surface parameters-   //-   // _VertexRegister [0 . . . 15] address of vertex register to output    parameters-   //-   #define D3DVSD_TESSUV(_VertexRegister)\    -   (D3DVSD_MAKETOKENTYPE(D3DVSD_TOKEN_TESSELLATOR)|0x10000000|\        -   ((0x01)<<D3DVSD_DATATYPESHIFT)|(_VertexRegister))-   // Generates END token-   //-   #define D3DVSD_END( ) 0xFFFFFFFF-   // Generates NOP token-   #define D3DVSD_NOP( ) 0x00000000-   // bit declarations for _Type fields-   #define D3DVSDT_FLOAT1 0x00 // 1D float expanded to (value, 0., 0.,    1.)-   #define D3DVSDT_FLOAT2 0x01 // 2D float expanded to (value, value,    0., 1.)-   #define D3DVSDT_FLOAT3 0x02 // 3D float expanded to (value, value,    value, 1.)-   #define D3DVSDT_FLOAT4 0x03 // 4D float-   #define D3DVSDT_D3DCOLOR 0x04 // 4D packed unsigned bytes mapped    to 0. to 1. range    -   // Input is in D3DCOLOR format (ARGB)-   expanded to (R, G, B, A)-   #define D3DVSDT_UBYTE4 0x05 // 4D unsigned byte-   #define D3DVSDT_SHORT2 0x06 // 2D signed short expanded to (value,    value, 0., 1.)-   #define D3DVSDT_SHORT4 0x07 // 4D signed short-   // assignments of vertex input registers for fixed function vertex    shader-   //-   #define D3DVSDE_POSITION 0-   #define D3DVSDE_BLENDWEIGHT 1-   #define D3DVSDE_BLENDINDICES 2-   #define D3DVSDE_NORMAL 3-   #define D3DVSDE_PSIZE 4-   #define D3DVSDE_DIFFUSE 5-   #define D3DVSDE_SPECULAR 6-   #define D3DVSDE_TEXCOORD0 7-   #define D3DVSDE_TEXCOORD1 8-   #define D3DVSDE_TEXCOORD2 9-   #define D3DVSDE_TEXCOORD3 10-   #define D3DVSDE_TEXCOORD4 11-   #define D3DVSDE_TEXCOORD5 12-   #define D3DVSDE_TEXCOORD6 13-   #define D3DVSDE_TEXCOORD7 14-   #define D3DVSDE_POSITION2 15-   #define D3DVSDE_NORMAL2 16-   // Maximum supported number of texture coordinate sets-   #define D3DDP_MAXTEXCOORD 8-   ;begin_internal-   //---------------------------------------------------------------------   //-   // Pixel Shader (PS) & Vertex Shader (VS) Instruction Token    Definition-   //-   // **** Version Token ****-   // [07:00] minor version number-   // [15:08] major version number-   // [31:16]-   // PS 0xFFFF-   // VS 0xFFFE-   //-   // **** End Token ****-   // [31:00] 0x0000FFFF-   //-   // **** Comment Token ****-   // [15:00] 0xFFFE-   // [30:16] DWORD Length (up to 2^15 DWORDS=128KB)-   // [31] 0x0-   //-   // **** Instruction Token ****-   // [15:00] Opcode (D3DSIO_*)-   // [23:16] Opcode-Specific Controls-   // [29:24] Reserved 0x0-   // [30] Co-Issue—if set then execute this instruction with the    previous instruction(s)-   // [31] 0x0-   //-   // **** Destination Parameter Token ****-   // [07:00] Register Number (offset in register file)-   // [15:08] Reserved 0x0-   //[19:16] Write Mask-   // [16] Component 0 (X;Red)-   // [17] Component 1 (Y;Green)-   // [18] Component 2 (Z;Blue)-   // [19] Component 3 (W;Alpha)-   // [23:20]-   // PS Result Modifier-   // VS Reserved 0x0-   // [27:24]-   // PS Result Shift Scale (signed shift)-   // VS Reserved 0x0-   // [30:28] Register Type-   // [0x0] Temporary Register File-   // [0x1] Reserved-   // [0x2] Reserved-   // [0x3]-   // VS Address Register (reg num must be zero)-   // PS Reserved-   // [0x4]-   // VS Rasterizer Output Register File-   // PS Reserved-   // [0x5]-   // VS Attribute Output Register File-   // PS Reserved-   // [0x6]-   // VS Texture Coordinate Register File-   // PS Reserved-   // [0x7] Reserved-   //[31] 0x1-   //-   // **** Source Parameter Token *****-   // [12:00] Register Number (offset in register file)-   // [13]-   // VS Relative Address-   // PS Reserved 0x0-   // [14:15]-   // VS Relative Address Register Component-   // PS Reserved 0x0-   // [23:16] Source Component Swizzle-   // [17:16] Component 0 Swizzle-   // [19:18] Component 1 Swizzle-   // [21:20] Component 2 Swizzle-   // [23:22] Component 3 Swizzle-   // [27:24] Source Modifier-   // [0x0] None-   // [0x1] Negate-   // [0x2] Bias-   // [0x3] Bias and Negate-   // [0x4] Sign-   // [0x5] Sign and Negate-   // [0x6] Complement-   // [0x7-0xf] Reserved-   // [30:28] Register Type-   // [0x0] Temporary Register File-   // [0x1] Input Register File-   // [0x2] Constant Register File-   // [0x3-0x7] Reserved-   // [31] 0x1-   //-   // The exception for source parameter tokens is with the    instruction:-   // D3DSIO_DEF c#,f0,f1,f2,f2-   // Here, the source parameter tokens (f#) are each taken as 32 bit    floats.-   //-   ;end_internal-   //-   // Instruction Token Bit Definitions-   //-   #define D3DSI_OPCODE_MASK 0x0000FFFF-   typedef enum_D3DSHADER_INSTRUCTION_OPCODE_TYPE-   {    -   D3DSIO_NOP=0, // PS/VS    -   D3DSIO_MOV, // PS/VS    -   D3DSIO_ADD, // PS/VS    -   D3DSIO_SUB, // PS    -   D3DSIO_MAD, // PS/VS    -   D3DSIO_MUL, // PS/VS    -   D3DSIO_RCP, // VS    -   D3DSIO_RSQ, // VS    -   D3DSIO_DP3, // PS/VS    -   D3DSIO_DP4, // PS/VS    -   D3DSIO_MIN, // VS    -   D3DSIO_MAX, // VS    -   D3DSIO_SLT, // VS    -   D3DSIO_SGE, // VS    -   D3DSIO_EXP, // VS    -   D3DSIO_LOG, // VS    -   D3DSIO_LIT, // VS    -   D3DSIO_DST, // VS    -   D3DSIO_LRP, // PS    -   D3DSIO_FRC, // VS    -   D3DSIO_M4x4, // VS    -   D3DSIO_M4x3, // VS    -   D3DSIO_M3x4, // VS    -   D3DSIO_M3x3, // VS    -   D3DSIO_M3x2, // VS    -   D3DSIO_TEXCOORD=64, // PS    -   D3DSIO_TEXKILL, // PS    -   D3DSIO_TEX, // PS    -   D3DSIO_TEXBEM, // PS    -   D3DSIO_TEXBEML, // PS    -   D3DSIO_TEXREG2AR, // PS    -   D3DSIO_TEXREG2GB, // PS D3DSIO_TEXM3x2PAD, // PS    -   D3DSIO_TEXM3x2TEX, // PS    -   D3DSIO_TEXM3x3PAD, // PS    -   D3DSIO_TEXM3x3TEX, // PS    -   D3DSIO_TEXM3x3DIFF, // PS    -   D3DSIO_TEXM3x3SPEC, // PS    -   D3DSIO_TEXM3x3VSPEC, // PS    -   D3DSIO_EXPP, // VS    -   D3DSIO_LOGP, // VS    -   D3DSIO_CND, // PS    -   D3DSIO_DEF, // PS-   ;begin_internal // PS    -   D3DSIO_RESERVED0=96, // PS    -   D3DSIO_RESERVED 1, // PS    -   D3DSIO_RESERVED2, // PS    -   D3DSIO_RESERVED3, // PS-   ;end_internal    -   D3DSIO_COMMENT=0xFFFE,    -   D3DSIO_END=0xFFFF,    -   D3DSIO_FORCE_DWORD=0x7fffffff, // force 32-bit size enum-   } D3DSHADER_INSTRUCTION_OPCODE_TYPE;-   //-   // Co-Issue Instruction Modifier—if set then this instruction is to    be-   // issued in parallel with the previous instruction(s) for which    this bit-   //is not set.-   //-   #define D3DSI_COISSUE 0x40000000-   //-   // Parameter Token Bit Definitions-   //-   #define D3DSP_REGNUM_MASK 0x00000FFF-   // destination parameter write mask-   #define D3DSP_WRITEMASK_(—)0 0x00010000 // Component 0 (X;Red)-   #define D3DSP_WRITEMASK_(—)1 0x00020000 // Component 1 (Y;Green)-   #define D3DSP_WRITEMASK_(—2 0)x00040000 // Component 2 (Z;Blue)-   #define D3DSP_WRITEMASK_(—3 0)x00080000 // Component 3 (W;Alpha)-   #define D3DSP_WRITEMASK_ALL 0x000F0000 // All Components-   // destination parameter modifiers-   #define D3DSP_DSTMOD_SHIFT 20-   #define D3DSP_DSTMOD_MASK 0x00F00000-   typedef enum_D3DSHADER_PARAM_DSTMOD_TYPE-   {    -   D3DSPDM_NONE=0<<D3DSP_DSTMOD_SHIFT, // nop    -   D3DSPDM_SATURATE=1<<D3DSP_DSTMOD_SHIFT // clamp to 0. to 1.        range    -   D3DSPDM_FORCE_DWORD=0x7fffffff, // force 32-bit size enum-   } D3DSHADER_PARAM_DSTMOD_TYPE;-   // destination parameter shift-   #define D3DSP_DSTSHIFT_SHIFT 24-   #define D3DSP_DSTSHIFT_MASK 0x0F000000-   // destination/source parameter register type-   #define D3DSP_REGTYPE_SHIFT 28-   #define D3DSP_REGTYPE_MASK 0x70000000-   typedef enum_D3DSHADER_PARAM_REGISTER_TYPE-   {    -   D3DSPR_TEMP=0<<D3DSP_REGTYPE_SHIFT, // Temporary Register File    -   D3DSPR_INPUT=1<<D3DSP_REGTYPE_SHIFT, // Input Register File    -   D3DSPR_CONST=2<<D3DSP_REGTYPE_SHIFT, // Constant Register File    -   D3DSPR_ADDR=3<<D3DSP_REGTYPE_SHIFT, // Address Register (VS)    -   D3DSPR_TEXTURE=3<<D3DSP_REGTYPE_SHIFT, // Texture Register File        (PS)    -   D3DSPR_RASTOUT=4<<D3DSP_REGTYPE_SHIFT, // Rasterizer Register        File    -   D3DSPR_ATTROUT=5<<D3DSP_REGTYPE_SHIFT, // Attribute Output        Register File    -   D3DSPR_TEXCRDOUT=6<<D3DSP_REGTYPE_SHIFT // Texture Coordinate        Output Register File    -   D3DSPR_FORCE_DWORD=0x7fffffff, // force 32-bit size enum-   } D3DSHADER_PARAM_REGISTER_TYPE;-   // Register offsets in the Rasterizer Register File-   //-   typedef enum_D3DVS_RASTOUT_OFFSETS-   {    -   D3DSRO_POSITION=0,    -   D3DSRO_FOG,    -   D3DSRO_POINT_SIZE,    -   D3DSRO_FORCE_DWORD=0x7fffffff, // force 32-bit size enum-   } D3DVS_RASTOUT_OFFSETS;-   // Source operand addressing modes-   #define D3DVS_ADDRESSMODE_SHIFT 13-   #define D3DVS_ADDRESSMODE_MASK (1<<D3DVS_ADDRESSMODE_SHIFT)-   typedef enum_D3DVS_ADDRESSMODE_TYPE-   {    -   D3DVS_ADDRMODE_ABSOLUTE=(0<<D3DVS_ADDRESSMODE_SHIFT),    -   D3DVS_ADDRMODE_RELATIVE=(1<<D3DVS_ADDRESSMODE_SHIFT), //-   Relative to register AO    -   D3DVS_ADDRMODE_FORCE_DWORD=0x7fffffff, // force 32-bit size enum-   } D3DVS_ADDRESSMODE_TYPE;-   // Source operand swizzle definitions-   //-   #define D3DVS_SWIZZLE_SHIFT 16-   #define D3DVS_SWIZZLE_MASK 0x00FF0000-   // The following bits define where to take component X:-   #define D3DVS_X_X (0<<D3DVS_SWIZZLE_SHIFT)-   #define D3DVS_X_Y (1<<D3DVS_SWIZZLE_SHIFT)-   #define D3DVS_X_Z (2<<D3DVS_SWIZZLE_SHIFT)-   #define D3DVS_X_W (3<<D3DVS_SWIZZLE SHIFT)-   // The following bits define where to take component Y:-   #define D3DVS_Y_X (0<<(D3DVS_SWIZZLE_SHIFT+2))-   #define D3DVS_Y_Y (1<<(D3DVS_SWIZZLE_SHIFT+2))-   #define D3DVS_Y_Z (2<<(D3DVS_SWIZZLE_SHIFT+2))-   #define D3DVS_Y_W (3<<(D3DVS_SWIZZLE_SHIFT+2))-   // The following bits define where to take component Z:-   #define D3DVS_Z_X (0<<(D3DVS_SWIZZLE_SHIFT+4))-   #define D3DVS_Z_Y (1<<(D3DVS_SWIZZLE_SHIFT+4))-   #define D3DVS_Z_Z (2<<(D3DVS_SWIZZLE_SHIFT+4))-   #define D3DVS_Z_W (3<<(D3DVS_SWIZZLE_SHIFT+4))-   // The following bits define where to take component W:-   #define D3DVS_W_X (0<<(D3DVS_SWIZZLE_SHIFT+6))-   #define D3DVS_W_Y (1<<(D3DVS_SWIZZLE_SHIFT+6))-   #define D3DVS_W_Z (2<<(D3DVS_SWIZZLE_SHIFT+6))-   #define D3DVS_W_W (3<<(D3DVS_SWIZZLE_SHIFT+6))-   // Value when there is no swizzle (X is taken from X, Y is taken    from Y,-   // Z is taken from Z, W is taken from W-   //-   #define D3DVS_NOSWIZZLE (D3DVS_X_X|D3DVS_Y_Y|D3DVS_Z_Z|D3DVS_W_W)-   // source parameter swizzle-   #define D3DSP_SWIZZLE_SHIFT 16-   #define D3DSP_SWIZZLE_MASK 0x00FF0000-   #define D3DSP_NOSWIZZLE \    -   ((0<<(D3DSP_SWIZZLE_SHIFT+0))|\        -   (1<<(D3DSP_SWIZZLE_SHIFT+2))|\        -   (2<<(D3DSP_SWIZZLE_SHIFT+4))|\        -   (3<<(D3DSP_SWIZZLE_SHIFT+6)))-   // pixel-shader swizzle ops-   #define D3DSP_REPLICATEALPHA \    -   ((3<<(D3DSP_SWIZZLE_SHIFT+0))|\        -   (3<<(D3DSP_SWIZZLE_SHIFT+2))|\        -   (3<<z(D3DSP_SWIZZLE_SHIFT+4))|\        -   (3<<(D3DSP_SWIZZLE_SHIFT+6)))-   // source parameter modifiers-   #define D3DSP_SRCMOD_SHIFT 24-   #define D3DSP_SRCMOD_MASK 0x0F000000-   typedef enum_D3DSHADER_PARAM_SRCMOD_TYPE-   {    -   D3DSPSM_NONE=0<<D3DSP_SRCMOD_SHIFT, // nop    -   D3DSPSM_NEG=1<<D3DSP_SRCMOD_SHIFT, // negate    -   D3DSPSM_BIAS=2<<D3DSP_SRCMOD_SHIFT, // bias    -   D3DSPSM_BIASNEG=3<<D3DSP_SRCMOD_SHIFT, // bias and negate    -   D3DSPSM_SIGN=4<<D3DSP_SRCMOD_SHIFT, // sign    -   D3DSPSM_SIGNNEG=5<<D3DSP_SRCMOD_SHIFT, // sign and negate    -   D3DSPSM_COMP=6<<D3DSP_SRCMOD_SHIFT, // complement    -   D3DSPSM_FORCE_DWORD=0x7fffffff, // force 32-bit size enum-   } D3DSHADER_PARAM_SRCMOD_TYPE;-   // pixel shader version token-   #define D3DPS_VERSION(_Major,_Minor)    (0xFFFF00000|((_Major)<<8)|(_Minor))-   // vertex shader version token-   #define D3DVS_VERSION(_Major,_Minor)    (0xFFFE0000|((_Major)<<8)|(_Minor))-   // extract major/minor from version cap-   #define D3DSHADER_VERSION_MAJOR(_Version) (((_Version)8)&0xFF)-   #define D3DSHADER_VERSION_MINOR(_Version) (((_Version)0)&0xFF)-   // destination/source parameter register type-   #define D3DSI_COMMENTSIZE_SHIFT 16-   #define D3DSI_COMMENTSIZE_MASK 0x7FFF0000-   #define D3DSHADER_COMMENT(_DWordSize)\-   (((_DWordSize)<<D3DSI_COMMENTSIZE_SHIFT)&D3DSI_COMMENTSIZE_MASK)|D3DSI    O_COMMENT)-   // pixel/vertex shader end token-   #define D3DPS_END( ) 0x0000FFFF-   #define D3DVS_END( ) 0x0000FFFF.

While the above exemplary computer-executable instructions have beendescribed in the context of a procedural shader, these concepts andprinciples may be applied to any 3D hardware rendering device utilizedin connection with a graphics display system.

Improvements on the Display (Rasterizer) Side of the API

As mentioned above, while direct video memory access was once apossibility, it is no longer a possibility according to today'scurrently utilized graphics architectures. In accordance with today'sgraphics pipeline architecture, specialized or private drivers andsurface formats are used in connection with very fast graphicsaccelerators. With direct rasterizer/processor access to display memorysurfaces, “chunks” of surfaces can be moved around according to thespecialized surface format, and pulled for processing as efficiencydictates. Thus, the pipeline between display memory surface space andthe display itself has been made more efficient. With reference to FIG.7A, an example of the type of modem ‘chunk’ manipulation is illustratedat a microcosmic level i.e., only 4 squares or chunks of data areillustrated. Private driver 700 causes chunks 710 a_1 through 710 a_4 tobe grabbed as efficiency dictates and are subsequently manipulated witha rasterizer into an intermediate form 710 b, wherein the original imagemay be unrecognizable. Then, data is moved along the graphics pipelineto render the final image on display 710 c, whereby band B_1 of data maytranslate to band B_2 in the displayed image. These mathematicaltransformations, and timing thereof, have advanced algorithms fordetermining the efficiency of chunk grabbing and placement. In essence,many images involve redundant data, or data that can be exploited basedupon temporal and spatial knowledge, and these algorithms exploit suchknowledge to create an extremely efficient and fast graphics datarendering pipeline.

Without the API of the present invention, however, display memorysurface space must be set up properly by the developer to work with thisprivatized format. FIG. 7B illustrates API 340 in accordance with thepresent invention. The API object 340_1 of the present invention hidesthe efficiencies gained from the privatized driver format and rasterizeroperation as described above from applications and developers. As far asthe developer D1 writing application 350 a is concerned, the displaymemory surface 710 a receives a rectangular image that is then renderedupon the display 710 c, when in fact many efficient operations and datamanipulations take place behind the scenes. The present invention thusimplements API object 340_1 such that it exposes more of these efficientpipeline operations to the developer D1 so that developer D1 need beless concerned with the performance of hidden operations, such aslocking and unlocking the privatized formats pursuant to variouscommands and function calls over which the developer has no control.

Currently, when data is stored in hardware memory, the data isimplemented in the privatized format illustrated in FIG. 7A. Whengraphics data is stored in main memory, it is stored in the public, moreeasily understood format. The privatized driver performs thistransition. However, previously when graphics data stored in thehardware memory was asked for pursuant to some command or function call,the data was shuffled back to the public format, and then transmittedaccording to the private format for hardware purposes. Thus, upon an‘unlock’ command, the data was copied to system memory in the publicformat, and then the data was transformed to the privatized format wherenecessary. Unfortunately, a problem arises wherein the same data may be‘unlocked’ from hardware memory according to multiple function calls orcommands, and consequently, multiple copies of the same data may becopied to the system memory. The present invention addresses thisproblem by only allowing data to be copied into system memory space whenthe developer specifically makes such a request, and thus ensuring thatonly copies that the developer knows about are resident in the system.Reductions in performance as a result of multiple copies resident inmain memory, when unnecessary, are thus avoided. In recognition that thedata does not always need to be accessed from system memory space, thepresent invention thus allows the developer more freedom to command whendata is copied to system memory when stored in the privatized formatassociated with hardware memory.

Optimal Switching of Data Objects among Memory Locations

As described in the background, there are generally two types ofcontainers or data structures that the API presents to a developer foruse: one for pixels and one for polygons. Essentially, through passingarguments to the API (placing data into the containers), the developerscan manipulate various graphics data structures. Once these containersare filled with data, there are various places, such as system memory oron a 3D card or chip, where this data may stored for furthermanipulation. The decision as to where to place this data is generally aperformance issue. For instance, data for which fast access is notnecessary can be stored in system memory, whereas data for which speedof access is the most important may be stored on a chip designed forultra fast access. It is also sometimes the case that it is desirable toswitch data or chunks of data from one memory location to another memorylocation at different stages of processing.

As illustrated in FIG. 8A, in the past, when a developer switched datafrom one memory location to another, the developer had to code theswitching the data i.e., by destroying the data in the old location andrecreating the data in the new location. Developer D1, after creating adata container 850 or deleting and recreating a data container 850 viagraphics API 340, has the decision to make regarding where to place thenew data container 850. While a developer may choose into which ofsystem memory 800, graphics chip memory 810 and other memory 820 datacontainer 850 is placed, oftentimes, a developer D1 may write a customcache managing algorithm for application 350 a in an effort toefficiently manage resources. In theory, the cache managing algorithmwould try to account for all of the system parameters and attempt tomanage memory based upon data location, frequency of accessing orprocessing the data, and processing times associated with certainlocations. However, this is a great inconvenience to developer D1 whohas to custom build each cache managing algorithm for each newapplication 350 a, and who through oversight may not manage resources asefficiently as possible.

As shown in FIG. 8B, in accordance with the present invention, theswitching of data containers 850 from one location to another isperformed automatically by an API object 340_cm. Thus, polygon or pixeldata objects 850 are automatically transitioned between memory typessuch that the switching is seamless. It appears as if the datachunks/containers 850 last forever to the developer, whereas in reality,the API hides the fact that the data is being transitioned to optimizesystem performance. For example, it would in theory be desirable to keepall data on the faster hardware chip memory to process data. However, inreality, there is little room for such on chip data, sometimes as few asa hundred registers. Thus, typically a cache managing algorithmoptimizes the tradeoff between host system memory and video memory onthe 3D card so as to keep a maximum amount of data for processing ingraphics hardware memory without causing overflow. As alluded to above,currently, a developer has to write such a cache managing algorithm forevery application that is individually tailored to the programming taskat hand. The API 340 of the present invention hides an optimal cachemanaging algorithm from developer D1 so that developer D1 need not beconcerned with the optimal tradeoff of system resources, and so thatefficient switching of data can take place ‘behind the scenes’simplifying the developer's task. Data containers 850 are thusefficiently placed in storage to maximize data processing rates, andstorage space, whether a data container 850 is newly created, orswitched from one location to another.

Parallel Feeding of Data Objects to 3D Chip for Processing

There are also current issues with respect to the transmission of datacontainers 850, either pixel and polygon, to a 3D chip. Currently, whena developer goes about specifying multiple data objects to fill multiplecontainers, these data objects are fed to the 3D chip one by one, or ina serial fashion. As illustrated in FIG. 9A, currently, to feed two datacontainers 850 a and 850 b to graphics chip memory 810, developer D1must feed the objects serially to memory 810. In the figure, t1<t2. Att1, container 850 a is retrieved from wherever stored or is created andat t2, it is fed to 3D graphics chip memory 810. In a typicalrepresentation of a pixel with eight bits, x, y, z and w may be utilizedfor the spatial position of the pixel and four more o1, o2, o3 and o4may be utilized to represent the orientation of the surface, or coloretc. at that position. When the position and location of graphics datais constantly changing, serial transmission or loading of graphics chipmemory may not reduce performance significantly. However, when there isredundancy of data e.g., when only the orientation of a pixel changeswhile the spatial position stays the same, opportunity to exploit theredundancy is lost. Thus, serialized data in container 850 a is fed to3D graphics chip memory 810. As will become evident, Even when performedvery fast, the serial transmission of data containers 850 a and 850 b isnot as fast as a parallel transmission when there is some redundancy orother reason to transmit data in parallel.

Thus, an optimization in accordance with the present invention is that adeveloper coding an application may specify that multiple of these dataobjects wherever originated or located at the time of operation, may befed to the 3D chip simultaneously or in parallel. As illustrated in FIG.9B, both containers 850 a and 850 b may be fed to 3D graphics chipmemory 810 at the same time. At t1, the data containers 850 a and 850 bare retrieved or created, and at t2, containers 850 a and 850 b are fedto 3D graphics chip memory in parallel. While FIG. 9B illustrates theparallel transmission of two data containers to 3D graphics chip memory810, any number of data containers up to the maximum storage of 3Dgraphics chip memory 810 may be fed in parallel. Thus, in the case ofthe above example where data is being transmitted to 3D graphics chipmemory 810, wherein the data includes the same spatial position ofpixel(s), but only the orientation or color is changing, the data may beloaded into two separate containers 850 a and 850 b, with a headerdescription understood by the graphics chip and implemented by graphicsAPI 340, whereby a single copy of the position data can be loaded intocontainer 850 a, and the changing color or orientation data may beloaded into container 850 b. Thus, when received by the graphics chip810, the data is loaded correctly into register space and processedaccording to the header description. In an exemplary implementation, upto 8 data objects 850 a, 850 b, etc. may be fed in parallel to thegraphics chip 810. In such a configuration, the exploitation ofredundancies may be performed in connection with any of the 8 valuesutilized to represent a pixel's location, orientation, etc. The presentinvention thus supplements previous systems in which data could only befed serially to a graphics chip with parallel feeding of graphics data.

The term graphics data as used herein is intended to cover not onlyvideo and/or audio data in any pre-processed, processed or compressedform, but is additionally intended to cover communications of data ofany kind along the graphics pipeline among the developer, the softwareinterface of the present invention and various hardware and/or softwarecomponents utilized incident to the graphics system.

The various techniques described herein may be implemented with hardwareor software or, where appropriate, with a combination of both. Thus, themethods and apparatus of the present invention, or certain aspects orportions thereof, may take the form of program code (i.e., instructions)embodied in tangible media, such as floppy diskettes, CD-ROMs, harddrives, or any other machine-readable storage medium, wherein, when theprogram code is loaded into and executed by a machine, such as acomputer, the machine becomes an apparatus for practicing the invention.In the case of program code execution on programmable computers, thecomputer will generally include a processor, a storage medium readableby the processor (including volatile and non-volatile memory and/orstorage elements), at least one input device, and at least one outputdevice. One or more programs are preferably implemented in a high levelprocedural or object oriented programming language to communicate with acomputer system. However, the program(s) can be implemented in assemblyor machine language, if desired. In any case, the language may be acompiled or interpreted language, and combined with hardwareimplementations.

The methods and apparatus of the present invention may also be embodiedin the form of program code that is transmitted over some transmissionmedium, such as over electrical wiring or cabling, through fiber optics,or via any other form of transmission, wherein, when the program code isreceived and loaded into and executed by a machine, such as an EPROM, agate array, a programmable logic device (PLD), a client computer, avideo recorder or the like, the machine becomes an apparatus forpracticing the invention. When implemented on a general-purposeprocessor, the program code combines with the processor to provide aunique apparatus that operates to perform the indexing functionality ofthe present invention. For example, the storage techniques used inconnection with the present invention may invariably be a combination ofhardware and software.

While the present invention has been described in connection with thepreferred embodiments of the various figures, it is to be understoodthat other similar embodiments may be used or modifications andadditions may be made to the described embodiment for performing thesame function of the present invention without deviating therefrom. Forexample, while exemplary embodiments of the invention are described inthe context of graphics data in a PC with a general operating system,one skilled in the art will recognize that the present invention is notlimited to the PC, and that a 3D graphics API may apply to any computingdevice, such as a gaming console, handheld computer, portable computer,etc., whether wired or wireless, and may be applied to any number ofsuch computing devices connected via a communications network, andinteracting across the network. Furthermore, it should be emphasizedthat a variety of computer platforms, including handheld deviceoperating systems and other application specific operating systems arecontemplated, especially as the number of wireless networked devicescontinues to proliferate. Therefore, the present invention should not belimited to any single embodiment, but rather construed in breadth andscope in accordance with the appended claims.

1. A graphics processing unit (GPU) for processing data in a graphicssystem on behalf of a host, comprising: an interface component that,upon receipt of at least one host graphics application programminginterface (API) call, receives and unpackages a plurality of algorithmicelements from the at least one host graphics API call, wherein eachalgorithmic element is downloadable to the GPU as an instruction setpacked into an array of numbers by a host graphics API, represents acomputational algorithm, and contains one or more tokens selected by adeveloper from a list of tokens interpretable by the GPU, said array ofnumbers for the selected one or more tokens providing an instruction tobe performed by at least one computational subunit of the GPU; and amapping component that maps the unpackaged plurality of algorithmicelements to at least one computational subunit of the GPU according to apre-defined protocol for interpreting the at least one host graphics APIcall, thereby readying the GPU to implement the instructions for thetokens selected by the developer so as to perform the functionalityrepresented by the plurality of algorithmic elements based on thedeveloper's selection of tokens interpretable by the GPU.
 2. A GPUaccording to claim 1, further comprising: a processing component that,upon receipt of at least one API call specifying graphics data forprocessing according to the functionality represented by the pluralityof algorithmic elements, processes said graphics data according to saidfunctionality.
 3. A GPU according to claim 2, wherein said graphics datais vertex data specifying at least one vertex of a graphics object.
 4. AGPU according to claim 2, wherein said graphics data is pixel dataspecifying at least one pixel of a graphics object.
 5. A GPU accordingto claim 1, wherein said receipt of at least one host graphics API callby the interface component includes receipt of said array of numbers. 6.A GPU according to claim 5, whereby said interface component unpackagesthe plurality of algorithmic elements from the array of numbers.
 7. AGPU according to claim 6, whereby said interface component unpackagesthe plurality of algorithmic elements from the array of numbers byreferring to said list of tokens interpretable by the GPU.
 8. A GPUaccording to claim 1, whereby said mapping component maps the unpackagedplurality of algorithmic elements to at least one procedural shader ofthe GPU according to the pre-defined protocol.
 9. A GPU according toclaim 1, wherein the plurality of algorithmic elements compriseinstructions for at least one of lighting, colorizing, mapping,texturizing, surfacing, shading, and enhancing an image.
 10. A GPUaccording to claim 1, wherein said interface component unpackages saidplurality of algorithmic elements based on a declaration portionincluded in said host graphics API call.
 11. A GPU according to claim10, wherein said declaration portion includes assignment information forassigning at least one input register of the at least one computationalsubunit to corresponding data streams specified by said host graphicsAPI call.
 12. A GPU according to claim 11, wherein said assignmentinformation is for assigning at least one input register to a dataelement within a data stream.
 13. A GPU according to claim 12, whereinsaid assignment information is for assigning at least one input registerto a vertex element within a vertex stream.
 14. A GPU according to claim13, wherein the vertex element of the vertex stream is identified by abyte offset within the vertex stream and a type.
 15. A GPU according toclaim 10, wherein said declaration portion includes assignmentinformation for assigning at least one input register of the at leastone computational subunit to data output from a tessellator subunit ofthe GPU.
 16. A GPU according to claim 10, wherein said declarationportion includes assignment information for assigning values to constantmemory of the at least one computational subunit.
 17. A GPU according toclaim 16, wherein said assignment information includes a token thatspecifies values for one or more contiguous groups of storage locationsof the constant memory of the at least one computational subunit.
 18. AGPU according to claim 16, wherein said declaration portion includesassignment information for updating an arbitrary subset of the constantmemory, including assignment information for overwriting the devicestate.
 19. A GPU according to claim 10, wherein said declaration portionincludes at least one stream selector token followed by a contiguous setof stream data definition tokens.
 20. A GPU according to claim 19,wherein the contiguous set of stream data definition tokens define astream, including the set of elements within the stream, the order inwhich the elements of the stream appear, the type of each element, andthe register into which to load each element.
 21. A GPU according toclaim 20, wherein a stream is allowed to include at least one elementwhich is not loaded into a register.
 22. A GPU according to claim 1,wherein the interface component further transmits data objects to theGPU in respective data containers in parallel.
 23. A video cardcomprising: a video memory; and a graphics processing unit (GPU)comprising: an interface component that, upon receipt of at least onehost graphics application programming interface (API) call, receives andunpackages a plurality of algorithmic elements from the at least onehost graphics API call, wherein each algorithmic element is downloadableto the GPU as an instruction set packed into an array of numbers by ahost graphics API, represents a computational algorithm, and containsone or more tokens selected by a developer from a list of tokensinterpretable by the GPU, said array of numbers for the selected one ormore tokens providing an instruction to be performed by at least onecomputational subunit of the GPU; and a mapping component that maps theunpackaged plurality of algorithmic elements to at least onecomputational subunit of the GPU according to a pre-defined protocol forinterpreting the at least one host graphics API call, thereby readyingthe GPU to implement the instructions for the tokens selected by thedeveloper so as to perform the functionality represented by theplurality of algorithmic elements based on the developer's selection oftokens interpretable by the GPU.
 24. A video card according to claim 23,wherein the interface component further transmits data objects to theGPU in respective data containers in parallel.